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REMARKS 

Applicant thanks the Examiner for a thorough examination and the withdrawal of the 
rejection of claims 1-16 under 35 U.S. C. § 101, and the rejection of claims 20 and 21 under 
35 U.S.C. § 1 12, second paragraph, but respectfully requests reconsideration of the present 
application in view of the foregoing amendments and in view of the reasons that follow. 

Claims 1, 5, 8, 16, 17, and 21 are currently being amended. 

This amendment adds, changes and/or deletes claims in this application. A detailed 
listing of all claims that are, or were, in the application, irrespective of whether the claim(s) 
remain under examination in the application, is presented, with an appropriate defined status 
identifier. 

After amending the claims as set forth above, claims 1-21 are now pending in this 
application. 

I. Claim Rejections -35 U.S.C. §101 

In the outstanding Office Action, claims 17-19 were rejected under 35 U.S.C. § 101, 
for being directed to non-statutory subject matter. In the Examiner's opinion, despite the 
recitation of a "system" in independent claim 17, the components comprising the system may 
be interpreted to be software per se. 

In response to the rejection, Applicant has amended independent claim 17 to more 
particularly recite that the consumer application is "executable by a processing unit" in 
accordance with the Examiner's suggestion. Support for this amendment can be found at, 
e.g., paragraph [0062] of the present application. 

II. Claim Rejections - 35 U.S.C. § 102(b) 

In the outstanding Office Action, claims 1-3 and 5-23 were again rejected under 35 
U.S.C. § 102(b) as being anticipated by U.S. Patent No. 7,194,743 (Hayton et al.) Applicant 
traverses the rejection for the reasons set forth below. 
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It should be noted that Applicant incorporates herein by reference in their entirety, the 
arguments regarding the rejection of claims 1-3 and 5-23 as presented in Applicant's April 
24, 2008, October 20, 2008, May 5, 2009 Replies. 

With regard to independent claims 1,8, and 17 of the present application, the 
Examiner has again maintained his assertion that Hayton et al. teaches all of the required 
limitations recited therein. Additionally, the Examiner has provided responses to Applicant's 
arguments at pages 4-7 of the outstanding Office Action. 1 

In response to Applicant's arguments that Hayton is directed to a "development" 
environment (where users "develop" the appearance of a UI), the Examiner asserted at 
Section 1 of the outstanding Office Action that various portions of Hayton et al. allegedly 
support the interpretation that dynamically altering the UI of Hayton et al. reads on the 
claimed dynamic addition of features to an application. Furthermore, the Examiner asserted 
that if adding elements to a UI of Hayton et al. is considered to be a "development" process, 
then "the claimed invention is also at the development time unless the claim indicates 
otherwise." Further still, the Examiner asserted that applicant's specification fails to 
explicitly define the claimed "feature" (and thus, menu commands, text, data, values, etc. as 
described in Hayton et al. read on the claimed feature), and that Applicant has provided 
contradictory arguments. 

First, Applicant submits that the Examiner has merely cited to the same sections of 
Hayton et al. that Applicant has repeatedly argued as failing to teach the dynamic addition of 
a feature to an application, without addressing Applicant's arguments. 

Second, Applicant submits that the Examiner's position that if Hayton et al. is 
directed to a development process, then so must the claimed embodiments of the present 
application, is circuitous and the result of presupposition. That is, and as explicitly recited in 
independent claims 1, 8, and 17, the dynamic addition of features to an application is in 
response to "consumer" interest of a "consumer" application, using the consumer interest and 



1 Page 3 of the outstanding Office Action outlines, in the Examiner's opinion, a summary of Applicant's 
previously presented arguments, the sections of which are referenced herein. 
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feature capability to identify a provider, and providing the feature to the consumer 
application. Hence, Applicant submits that the claims are abundantly clear and distinguished 
from a user (i.e., developer) that is merely developing a UI as opposed to, e.g., a user (i.e., 
consumer). It appears that the Examiner is misinterpreting the "user" described in the 
disclosure of Hayton et al. as being a developer, as being commensurate to a "consumer" as 
claimed in independent claims 1, 8, and 17 of the present application. As will be described in 
greater detail below, an end user may interact with the developed UI of Hayton et al., but only 
after its development by the developer. Applicant submits that Hayton et al. is very clear in 
that the user described therein is a "developer" not a "consumer." Therefore, the dynamic 
addition of values that may appear in a field of the UI is not analogous to the dynamic 
addition of features to an application as recited in independent claims 1,8, and 17 of the 
present application. 

Moreover and contrary to the Examiner's assertions, the specification of the present 
application is replete not only with examples of "features" that would clearly be understood 
by those of ordinary skill in the art as being different from mere UI elements, but also with 
references to "features"/"applications" distinct from a UI. For example, the present 
application indicates that: 

Typically, an application provides the functionality for a feature 
that is visible to an end-user in a pre-defined shell application . 
The application menu and other user interface elements , like 
soft key buttons or selection lists, offers sets of choices or data 
available per feature . 

{See, paragraph [0004] of the present application), (emphasis added). 

Briefly, one exemplary embodiment relates to a method for 
adding computer software features dynamically to a software 
application . . . that adds any feature to any application. . .adding 
the desired user interface elements to a user interface associated 
with the software application . 

{See, paragraph [0019] of the present application), (emphasis added). 

From the above, it is clearly shown that while a feature may be added to an application 
and represented by user interface elements, the feature in and of itself is separate from a UI/UI 
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element. Moreover, and in accordance with Applicant's arguments, Applicant again submits 
Hayton et al. itself distinguishes between applications and UIs by virtue of the different terms 
utilized. That is and as previously argued by Applicant (and unanswered/unrebutted by the 
Examiner), Hayton et al. utilizes the term "application" separately from the term "UI," clearly 
suggesting that the UI is not the same as an application. 

Further still, Column 9, lines 5-6 and 9-13, and Column 19, lines 57-60 of Hayton et 
al. clearly also suggest that any elements/properties must already be known/predefined, and 
hence, not dynamic as in the context of independent claims 1,8, and 17 of the present 
application. For example, Column 9, lines 5-6 indicate that "[t]he system takes advantage of 
the fact that most user-interfaces are essentially static." Column 9, lines 9-13 indicate that 
"[t]he dynamic aspect of a user-interface generally consists of changes to the static page 
'template' such as filling in fields. . ." Column 19, lines 57-60 recites that "[a] page 42 can 
also be altered dynamically when, for example, an iterator type predefined UI element. . ." 
Again, Hayton et al. is clear in that UI elements are "static" or predefined, where such 
properties need to be known at development time in order to make dynamic data addition 
possible for indexable property. In contrast, independent claims 1, 8, and 17 of the present 
application dynamically add new (e.g., previously unknown) features to an application 
(wherein the feature may be, e.g., visually represented by new UI features) Moreover, even if 
such a new feature is interpreted as a new UI feature, it remains that the UI feature is "new," 
and not, e.g., static or predefined. 

Moreover and in response to the Examiner's assertions that Applicant's arguments are 
contradictory, Applicant submits that applications are not the only "thing" or "entity" that 
may be developed by a developer. Clearly and as would be very well understood by those of 
ordinary skill in the art, a UI may be developed for an application, the UI being, as previously 
argued by Applicant, a "front-end" to the actual application. Hence, Applicant submits that 
none of Applicant's arguments are contradictory. 

Additionally, the Examiner asserted at Section 2 of the outstanding Office Action that 
in his opinion, the UI of Hayton et al. can be "interpreted" to be an application. Applicant 
submits that regardless of whether or not a UI may be in certain scenarios, considered to be 
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it's own application, such an interpretation is impermissible in the context of Hayton et al. 
That is and again, e.g., Column 2, lines 44-59 of Hayton et al., clearly indicate that Hayton et 
al. does not contemplate the UI to be it's own application, let alone a consumer application. 
For example, Hayton et al. describes the following: 

The present invention provides a mechanism by which the user- 
interface portion of the application can be delivered to the 
computer user either on the same machine on which the 
application is executing or on another machine remote from the 
machine executing the application. The invention separates the 
user-interface from the underlying application enabling the 
design of the user interface portion of the application to be 
relatively straightforward. . . 

These features give the user the effect of directly interacting 
with the application even though the application is potentially 
running somewhere else . 

(See, Column 2, lines 44-59 of Hayton et al.) (emphasis added). 

Yet again, Applicant submits that Hayton et al. is explicit in that the UI is merely the 
"front-end" of the "underlying application" and not an application in and of itself. In fact, 
Hayton et al. explicitly describes that the UI is actually "separated" from the underlying 
application, further suggesting that the Examiner's interpretation of the UI of Hayton et al. is 
erroneous. Moreover, once the UI has been developed by a developer, an end user interacts 
with the underlying "application" even though the application is remotely hosted relative to 
the end user. 

Additionally, the Examiner asserted at Section 3 of the outstanding Office Action that 
"the claim does not recite that the request is generated by the application interworking 
framework," and that "any request and communication is made between the client and the 
server must goes to and from the property connector. . ." First, Applicant submits that 
nowhere at, e.g., pages 10-11 of the previously filed response of May 5, 2009, does Applicant 
argue that generation is required. Second, Applicant submits that the request for the UI 42 
"by an end user" occurs after the UI 42 has been developed by the developer. Once an end 
user in Hayton et al. is able to interact with the UI, there is no longer any requesting of UI 
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elements or setting of property paths, etc. - the UI has already been developed. Therefore, it 
appears that the Examiner is confusing the development process of the UI with the later, 
actual interaction by an end user with the UI. 

Further still, the Examiner made various assertions at Section 4 of the outstanding 
Office Action regarding the server node of Hayton et al. and the provider aspect of 
independent claim 1, 8, and 17 of the present application. As already described above, once 
an end user interacts with the UI, the development of the UI, including any addition of UI 
elements has been performed by the developer. Moreover, the server as explicitly described 
at, e.g., Column 11, lines 43-48, is merely the entity that hosts the UI that can be accessed by 
an end user. There is no identification of a provider because the UI elements developed by 
the developer for the UI are already included, where the "dynamic" aspect of the UI elements, 
merely refers to the dynamic population of, e.g., fields within the UI element, not the dynamic 
addition of features or UI elements. 

With regard to independent claim 21 of the present application, Applicant submits that 
again, there is no "storage" of a user interface element corresponding to the consumer 
application interest resource in a file. Figure 3 and Column 15, lines 17-18 of Hayton et al. 
merely describe that in the development stage, a user (developer) can select "predefined" UI 
elements to develop the UI, which the Examiner cited to allegedly rebut, Applicant's 
arguments fail to read on such a feature. That is, the Examiner asserted at Section 5 of the 
outstanding Office Action that UI elements are "stored" in the API 22 (which the Examiner 
interpreted to read on the claimed application interworking framework). However, and as 
already described, this is merely a depiction of a development environment where a developer 
would choose predefined UI elements that have been stored to create the UI. 

In contrast, independent claim 2 1 requires the storage of a user interface element, and 
then "communicating" the user interface element "to" an application interworking 
framework. Applicant submits that following the Examiner's reasoning, the UI element 
would already be stored in the API (application interworking framework) and then would be 
communicated to the API (application interworking framework). Applicant is at a loss as to 
why it would be necessary to communicate a UI element to the same entity where the UI 
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element is already stored, and submits that the Examiner's reasoning would not result in the 
subject matter disclosed in independent claim 21 . 

With regard to the Examiner's remaining assertions/responses to Applicant's 
arguments pertaining to independent claim 21 at Sections 6 and 7 of the outstanding Office 
Action, Applicant submits that the Examiner's assertions are merely based upon the same 
mischaracterization/misinterpretation of Hayton et al. as already discussed above. Therefore, 
Applicant submits that Hayton et al. fails to read on each and every limitation recited in 
independent claim 21 for at least the same reasons. 

Additionally, and to further prosecution, Applicant has amended independent claims 
1, 8, 17, and 21 of the present application to more particularly recite that the claimed 
"feature"/"user interface element" are "new" and "dynamically" added. Dependent claims 5 
and 16 have also been amended for consistency purposes. Moreover, Applicant has amended 
independent claims 1,8, and 17 of the present application to more particularly recite the 
"consumer" aspect of various embodiments, by reciting "consumer application." Claims 1, 
17, and 21 of the present application have also been amended to more particularly recite that 
the consumer application is "installed on a consumer device." 

With regard to the teaching of a generic parameter, the Examiner asserted at Section 8 
of the outstanding Office Action that the term "generic parameter" recited in dependent 
claims 2, 12, and 22 of the present application, is not well known in the art, nor is it clearly 
described in the specification of the present application. Applicant disagrees. Paragraphs 
[0009], [0013], and [0049] -[0060] of the present application are replete with descriptions, 
comparisons to, e.g., specific function variants, and detailed examples of generic parameters, 
that would also be understood by those of ordinary skill in the art. Furthermore, Applicant 
submits that by virtue of claiming a "feature" and "generic parameters" the subject matter 
referred to by these different terms indicates a distinction. 

Moreover, Hayton et al. merely describes that properties are property paths used to 
refer to UI elements and these are passed via the API 1 1 using a nested referring scheme. In 
contrast and in accordance with the disclosure of the present application, generic parameters 
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may contain, e.g., both semantic ID and datatype ID that is carried between the consumer and 
provider enabling both static data agreement and dynamic (negotiated at run-time) between 
the consumer and provider. Further still, any such data agreement is not related to UI 
elements. {See, e.g., paragraphs [0052]-[0060] of the present application). 

With regard to dependent claim 11, the Examiner asserted at Section 9 of the 
outstanding Office Action that because UI 42 of Hayton et al. is created at the client computer 
and dynamically altered to include new features, "[t]he created UI 42 is now part of the client 
computer, e.g., integrate into the client computer as if part of the group of software 
applications running on the client computer." Applicant disagrees. 

As previously discussed in Applicant's May 5, 2009 Amendment and Reply, the 
specification of the present application at, e.g., paragraphs [0003] and [0004], as well as 
illustrated in, e.g., Figure 2, describes integrating the new feature/UI element "as if part of an 
original group of software applications." Again, e.g., paragraph [0004] of the present 
application, clearly indicates that a disadvantage of conventional systems and methods for 
adding features to an application is that UI elements, for example, may not look and behave 
as if they were originally part of the software application (as the new element representative 
of a new feature was added after development of the application). Applicant submits that as 
described at length above, Hayton et al. is merely directed to the development of a UI by a 
developer, and the ability for an end user to interact/access an application via the UI even if 
the application itself is remotely located from the end user. Thus, Hayton et al. fails to teach 
or contemplate the dynamic addition of, e.g., new features or UI elements, as if they were part 
of the original group of software applications, because any UI elements that were added to the 
UI would have been added at development time. Hayton et al. simply does not contemplate 
an integration feature such as that disclosed in dependent claim 1 1 of the present application. 

III. Claim Rejections - 35 U.S.C. § 103(a) 

In the outstanding Office Action, claim 4 was again rejected under 35 U.S.C. § 103(a) 
as being unpatentable over Hayton et al. in view of International Patent Application No. WO 
00/5885 (Gudmunson). Applicant traverses the rejection for the reasons set forth below. 
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The Examiner asserted at Section 10 of the outstanding Office Action that it is proper 
to combine the teachings of Hayton et al. and Gudmunson to arrive at each and every 
limitation recited by dependent claim 4 of the present application. Applicant disagrees. 
Applicant again submits that because Gudmunson was applied by the Examiner solely for 
purpose of evidencing the use of DLLs, Gudmunson cannot cure the deficiencies of Hayton et 
al. described above. Therefore, because claim 4 depends from independent claim 1 of the 
present application, Applicant submits that the alleged combination of Hayton et al. and 
Gudmunson still fail to teach all of the required limitations of claim 4 for at least the same 
reasons as discussed above. 

IV. Conclusion 

Because none of the references cited by the Examiner, either separately or in 
combination with each other, teach all of the required limitations recited in independent 
claims 1, 8, 17, and 21 of the present application, Applicant submits that each of these 
independent claims are patentable over this prior art. Furthermore, because dependent claims 
2-7, 9-16, 18-20, 22, and 23 are each directly or indirectly dependent upon independent 
claims 1, 8, 17, and 21, Applicant submits that each of these claims are allowable for at least 
the same reasons as discussed above in addition to those discussed with regard to dependent 
claims 2,4, 11, 12, and 22. 

Applicant believes that the present application is now in condition for allowance. 
Favorable reconsideration of the application as amended is respectfully requested. 

The Examiner is invited to contact the undersigned by telephone if it is felt that a 
telephone interview would advance the prosecution of the present application. 

The Commissioner is hereby authorized to charge any additional fees which may be 
required regarding this application under 37 C.F.R. §§ 1.16-1.17, or credit any overpayment, 
to Deposit Account No. 19-0741 . Should no proper payment be enclosed herewith, as by the 
credit card payment instructions in EFS-Web being incorrect or absent, resulting in a rejected 
or incorrect credit card transaction, the Commissioner is authorized to charge the unpaid 
amount to Deposit Account No. 19-0741 . If any extensions of time are needed for timely 
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acceptance of papers submitted herewith, Applicant hereby petitions for such extension under 
37 C.F.R. §1.136 and authorizes payment of any such extensions fees to Deposit Account No. 
19-0741. 



Respectfully submitted, 



Date: November 16. 2009 

FOLEY & LARDNER LLP 
Customer Number: 30542 
Telephone: (858) 847-6735 
Facsimile: (858) 792-6773 



By /G. Peter Albert, Jr./ 

G. Peter Albert Jr. 
Attorney for Applicant 
Registration No. 37,268 
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